Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift (1)

261-270: 사진 썸네일 표현 품질을 위해 contentMode 설정을 고려해 보세요.

현재 UIImageView에 배경색·cornerRadius만 지정되어 있어 실제 이미지를 로드하면 비율이 깨질 수 있습니다. 썸네일 용도라면 scaleAspectFill + clipsToBounds(true) 조합이 일반적입니다 (masksToBounds = true는 이미 설정되어 있으니 contentMode만 추가해도 효과가 있을 것 같습니다).

private func makePhotoView() -> UIImageView {
    let photoView = UIImageView()
    photoView.backgroundColor = BitnagilColor.gray30
    photoView.layer.masksToBounds = true
    photoView.layer.cornerRadius = 6
+   photoView.contentMode = .scaleAspectFill
    photoView.snp.makeConstraints { make in
        make.size.equalTo(Layout.photoSize)
    }
    return photoView
}

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 68
File: Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift:108-172
Timestamp: 2025-11-19T13:49:08.326Z
Learning: ReportCompleteViewController에서 backgroudView가 fomoImageView와 의도적으로 겹치도록 설계됨. 이를 위해 backgroudView의 top 제약을 fomoImageView.snp.top (또는 fomoImageView)을 기준으로 설정하여 오프셋을 적용함.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 68
File: Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift:108-172
Timestamp: 2025-11-19T13:49:08.326Z
Learning: ReportCompleteViewController에서 backgroudView가 fomoImageView와 의도적으로 겹치도록 설계됨. 이를 위해 backgroudView의 top 제약을 fomoImageView.snp.top (또는 fomoImageView)을 기준으로 설정하여 오프셋을 적용함.

Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift (1)

83-88: configureAttribute/configureLayout를 viewDidLoad에서 다시 호출하면 중복 초기화가 발생할 수 있습니다

BaseViewController의 viewDidLoad()에서 이미 configureAttribute(), configureLayout(), bind()를 호출하는 패턴이라면, 여기서 다시 직접 호출하면 서브뷰 추가·제약 설정이 두 번씩 일어나 Auto Layout 경고나 예기치 않은 UI 결과가 나올 수 있습니다 (이전에 같은 이슈가 한 번 지적된 적 있습니다).

이 컨트롤러도 ReportDetailViewController와 동일하게 super.viewDidLoad() 이후에는 액션만 호출하도록 정리하는 것이 안전해 보입니다.

    override func viewDidLoad() {
        super.viewDidLoad()
-        configureAttribute()
-        configureLayout()
        viewModel.action(input: .fetchReportDetail(reportId: reportId))
    }

Projects/Presentation/Sources/Report/Model/SelectPhotoType.swift (1)

8-9: 카메라/앨범 타입별 아이콘 매핑 무난합니다

SelectableItem.icon 요구사항에 맞게 BitnagilIcon 을 사용해 명확히 매핑되어 있고, 옵셔널 처리도 자연스럽습니다.
템플릿 컬러로 틴팅해야 하는 디자인이라면, 에셋 쪽에서 withRenderingMode(.alwaysTemplate) 적용 여부만 한 번 확인해 두면 좋겠습니다.

Also applies to: 38-45

Projects/Presentation/Sources/Common/DesignSystem/BitnagilIcon.swift (1)

79-80: 리포트용 카메라/사진 아이콘 추가 이상 없습니다

새 에셋 이름(bitnagil_camera_icon, bitnagil_photo_icon)과 SelectPhotoType.icon 사용처가 일관되고, 다른 아이콘 정의 방식과도 형식이 동일해서 유지보수에 문제 없어 보입니다.
필요하다면 이 아이콘도 다른 곳처럼 템플릿 렌더링(withRenderingMode(.alwaysTemplate))을 사용할지 디자인 가이드에 맞춰 통일만 고민해 보시면 될 것 같습니다.

Projects/Domain/Sources/Protocol/Repository/FileRepositoryProtocol.swift (1)

1-23: Presigned URL 반환 타입의 옵셔널 여부 한 번만 정리해 보면 좋겠습니다

fetchPresignedURL 이 [String: String]? 를 반환하도록 설계되어 있는데, FileRepository 구현에서는 현재 항상 non-optional 딕셔너리를 리턴하고 있어 실제로 nil 이 나올 상황이 거의 없어 보입니다.

• presigned URL 발급이 실패하면 throw 로 처리하고
• 성공 시에는 항상 모든 파일 이름에 대한 URL 을 받는 구조라면

반환 타입을 [String: String] 로 단순화해도 좋을 것 같습니다. 반대로, 일부 케이스에서 응답 바디가 없거나 비어 있을 수 있다면, 그 시나리오를 주석에 조금 더 명시해 두면 호출 측에서 이해하기 쉬울 것 같습니다.

Projects/Presentation/Sources/Common/Component/SelectableItemCell.swift (1)

14-18: 스택뷰 기반 레이아웃 전환은 괜찮습니다 (axis/size 세부 설정만 참고)

stackView 로 아이콘 + 타이틀을 묶고, 고정 높이/마진을 주는 구조는 명확하고 유지보수도 좋아 보입니다.
소소하게 고려해 볼 만한 부분은 아래 정도입니다.

• stackView.axis 는 기본값이 .horizontal 이라 현재도 동작에는 문제 없지만, 명시적으로 .horizontal 을 지정해 두면 의미가 더 분명해집니다.
• iconImageView 는 크기를 20pt 정사각형으로 고정해 두셨는데, 아이콘 에셋 비율에 따라 간혹 찌그러질 수 있어 contentMode = .scaleAspectFit 정도를 설정해 두면 안전합니다.
• stackView 에 width == 0 (priority .medium) 제약을 주신 부분은 레이아웃 경고 방지용 의도로 보이는데, 나중에 디버깅할 때 혼란을 줄 수 있으니, 실제로 필요한지 한 번 더 확인해 보시고 필요 없다면 제거하는 것도 옵션입니다.

전반적으로 기능적인 문제는 없어 보이고, 위 내용은 선택적인 정리 사항에 가깝습니다.

Also applies to: 20-22, 35-49, 51-66

Projects/DataSource/Sources/Repository/ReportRepository.swift (1)

14-38: 신규 report 구현은 일관적이지만, nil id 의미를 명확히 해두는 편이 좋습니다

ReportDTO 구성과 ReportEndpoint.register 호출 흐름은 ReportUseCase.report와 잘 맞습니다. 다만 networkService.request 결과가 nil인 경우를 그대로 nil id로 올려보내고 있어서, 상위 레이어에서 “요청 실패(에러)”와 “정상 응답이지만 id 없음”을 구분하기가 애매할 수 있습니다.

도메인에서 이 함수를 호출하는 쪽과 논의해,

• “id가 반드시 내려와야 한다”는 계약이라면 nil 대신 명시적인 도메인 에러를 throw 하거나,
• “id가 없을 수도 있다”는 스펙이라면 그 의미를 주석/문서에 남겨 두는 것
  을 고려해 보시면 좋겠습니다.

Projects/Domain/Sources/Entity/Enum/ReportType.swift (1)

8-18: rawValue가 이미 대문자라면 uppercased()는 불필요합니다

지금 케이스들의 rawValue가 "TRANSPORTATION", "LIGHTING" 등 이미 모두 대문자라서, description에서 한 번 더 uppercased()를 호출할 필요는 없습니다. 동작에는 문제가 없지만, 간결성을 위해 아래처럼 단순화할 수 있습니다.

-extension ReportType: CustomStringConvertible {
-    public var description: String {
-        return self.rawValue.uppercased()
-    }
-}
+extension ReportType: CustomStringConvertible {
+    public var description: String {
+        rawValue
+    }
+}

추후 소문자 rawValue를 도입해 API용 문자열을 따로 관리하고 싶다면, description 대신 apiValue 같은 별도 프로퍼티를 두는 것도 고려해 볼 수 있습니다.

Projects/Presentation/Sources/Report/View/ReportLoadingViewController.swift (1)

83-95: 제보 완료 화면 네비게이션 플로우 및 TODO 정리 제안

reportId 유무에 따라 완료 화면으로 push / 현재 VC pop 처리하는 delegate 플로우는 자연스럽습니다.
다만 Line 90의 TODO는 이미 reportId를 생성자 인자로 전달하고 있어 다소 중복·모호해 보이니, 최종적으로 id만 넘길지/엔티티 전체를 넘길지 결정된 뒤 TODO를 제거하거나 더 구체적인 FIXME 또는 이슈 링크로 정리해 두면 좋겠습니다.
아울러 ReportDetailViewModel 의존성이 Domain 쪽 DIAssembler에 정상 등록돼 있는지만 한 번만 확인 부탁드립니다.

Projects/Presentation/Sources/Home/View/HomeViewController.swift (1)

667-677: Report 제보 플로우의 ViewModel/문구 불일치

ReportRegistrationViewModel을 resolve 해서 ReportRegistrationViewController로 push 하는 구성은 새 제보 플로우와 일관됩니다.
다만 fatalError 메시지에는 "reportRegistrationViewController 의존성"이라고 되어 있어 실제 resolve하는 타입(ViewModel)과 이름이 맞지 않으니, "reportRegistrationViewModel 의존성이 등록되지 않았습니다."처럼 문구를 맞춰 두면 디버깅 시 더 명확할 것 같습니다.

Projects/Domain/Sources/Protocol/UseCase/ReportUseCaseProtocol.swift (1)

8-38: ReportUseCaseProtocol 메서드 시그니처/주석 정합성 양호

fetchReports / fetchReport / report(title:content:category:location:photos:) 추가가 실제 ReportUseCase 구현과 잘 맞고, 사진 업로드까지 포함한 도메인 요구사항이 명확히 드러납니다.
선택 사항이지만, fetchCurrentLocation·fetchReport처럼 nil을 반환할 수 있는 메서드에 대해 주석에 "조건 불충족 시 nil" 정도만 추가해 두면 호출 측에서 API를 이해하기 조금 더 수월할 것 같습니다.

Projects/DataSource/Sources/Endpoint/S3UploadEndpoint.swift (1)

10-63: S3Endpoint baseURL/path 및 헤더 조건 한 번만 확인 필요

presigned URL을 그대로 path로 넘기고 baseURL을 빈 문자열로 두는 구현은, 네트워크 레이어에서 baseURL·path를 어떻게 조합하는지에 따라 동작이 달라질 수 있습니다. 만약 URL(string: baseURL + path)처럼 단순 문자열 결합이면 문제 없지만, appendingPathComponent를 사용하는 경우 전체 URL이 잘못 조합될 수 있으니 NetworkService 구현과 함께 한 번만 확인해 주세요.

또한 presigned URL을 생성할 때 Content-Type 등 특정 헤더를 서명에 포함시키는지에 따라, 여기서 headers를 빈 딕셔너리로 두면 업로드가 실패할 가능성도 있습니다. 백엔드와 프로토콜을 맞춰 필요하다면 예를 들어 "Content-Type": "image/jpeg" 같은 헤더를 추가해 두는 편이 안전합니다.

Projects/Domain/Sources/Entity/ReportEntity.swift (1)

19-39: thumbnailURL / photoURLs 필드 추가는 적절하나 이름 일관성 제안

도메인 엔티티에 thumbnailURL과 photoURLs를 추가하고 id를 Optional로 바꾼 변경은 상위 레이어(예: 히스토리/상세 뷰모델)에서의 사용 방식과 잘 맞습니다.
다만 이니셜라이저의 파라미터 이름이 photoUrls이고 프로퍼티는 photoURLs라서 대소문자 규칙이 달라 약간 혼동될 수 있습니다. 아래처럼 파라미터 이름도 photoURLs로 맞추면 더 일관될 것 같습니다.

-        thumbnailURL: String?,
-        photoUrls: [String]
+        thumbnailURL: String?,
+        photoURLs: [String]
@@
-        self.thumbnailURL = thumbnailURL
-        self.photoURLs = photoUrls
+        self.thumbnailURL = thumbnailURL
+        self.photoURLs = photoURLs

Projects/Presentation/Sources/Report/ViewModel/ReportRegistrationViewModel.swift (2)

23-33: 검증/완료 Publisher의 Subject 설계 한 번만 점검해 보면 좋겠습니다

isReportValid를 PassthroughSubject로 두면, 구독 시점 이후 이벤트만 전달돼서 중간에 새로 구독하는 쪽은 현재 상태를 못 받을 수 있습니다. 뷰모델 라이프사이클 상 항상 뷰와 함께 생성·바인딩된다면 문제는 없지만, 혹시 재바인딩/재구독 가능성이 있다면 CurrentValueSubject<Bool, Never>로 바꿔 두는 편이 더 안전합니다. 반면 등록 완료 이벤트(reportRegistrationCompleteSubject)는 일회성 이벤트라 PassthroughSubject 선택이 적절해 보입니다.

Also applies to: 37-44, 52-61

---

134-172: 검증 로직과 register()의 guard 조건을 한 곳으로 모아 두면 유지보수가 더 수월할 것 같습니다

verifyIsReportValid()와 register()의 guard가 거의 동일한 조건을 중복해서 가지고 있습니다. 현재는 verifyIsReportValid 쪽만 lat/long까지 확인하고 있어, 나중에 요구사항이 바뀌면 두 곳을 동시에 수정해야 합니다.

예를 들어 “필수값이 모두 채워졌는지 판단하는 private computed property”를 두고, 그 값을 isReportValid 발행과 register()의 guard 양쪽에서 참조하도록 통합하면 조건 누락/불일치 위험이 줄어듭니다.

Also applies to: 174-190

Projects/Presentation/Sources/Report/View/ReportRegistrationViewController.swift (1)

47-49: 내용 글자 수 카운트 레이블의 최대 글자 수(150)를 상수로 분리해 두는 것이 좋아 보입니다

"150"이 레이블 텍스트("\(content.count) / 150"), UI/기획 스펙 양쪽에서 모두 쓰이는 매직 넘버라서, 예를 들어 Layout 내부나 별도 상수(static let maxContentLength = 150)로 정의해 두고 동일 값을 참조하면 나중에 정책이 바뀔 때 한 군데만 수정하면 되어 유지보수성이 좋아질 것 같습니다.

Also applies to: 67-69, 127-129, 284-294, 371-378

Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift (1)

204-235: bind()에서 summaryStackView 구성은 한 번만 만들고, 이후에는 값만 갱신하는 구조가 더 안전합니다

현재는 reportDetailPublisher가 emit될 때마다 ReportCompleteContent.allCases를 순회하며 makeContentView 결과를 summaryStackView에 계속 추가하고 있습니다. photoStackView는 매번 비워 주고 있지만, summaryStackView는 정리 없이 늘어날 수 있어(emit 1회라는 보장이 깨질 경우) 중복 뷰가 쌓일 여지가 있습니다.

• configureLayout() 혹은 configureAttribute()에서 ReportCompleteContent에 대한 컨텐츠 뷰를 한 번만 만들고 stack에 추가한 뒤,
• bind()에서는 각각의 레이블/이미지뷰에 값만 채우는 방식

으로 분리하면, emit 횟수와 관계없이 UI 구조가 안정적으로 유지됩니다.

Projects/Presentation/Sources/Report/ViewModel/ReportHistoryViewModel.swift (2)

34-35: 진행 상태(progress) 필터가 이제 항상 하나만 선택되는 구조인데, 토글 해제 UX가 필요하지 않은지 확인이 필요합니다

filterProgress에서 선택된 progress만 isSelected = true로 만들고, selectedProgress를 항상 해당 값으로 갱신한 뒤 filterReports()에서는

if let selectedProgress,
   selectedProgress != .entire {
    filteredReports = filteredReports.filter { $0.progress == selectedProgress }
}

로 동작하게 되어 있어, 한 번 progress를 누르면 다시 눌러도 해제(=전체로 돌아감)는 되지 않고, 대신 “전체” 칩을 눌러야만 전체 보기로 돌아가게 됩니다.

기획/UX가 “항상 하나의 진행 상태가 선택된 상태를 유지한다”는 의도라면 현재 구현이 적절해 보이고,
이전처럼 같은 항목을 다시 탭하면 필터를 해제하는 토글 UX를 원한다면, 동일 progress를 다시 선택했을 때 selectedProgress를 nil 또는 .entire로 되돌리는 로직이 필요합니다.

Also applies to: 85-100, 102-117

---

119-163: fetchReports()의 맵핑/카운트 로직은 도메인 변경에 잘 맞게 정리된 것 같습니다

• reportEntity.id를 guard let으로 필터링하고,
• 날짜 문자열을 Date.convertToDate → convertToString으로 변환한 뒤,
• thumbnailURL과 progress를 그대로 반영해 ReportHistoryItem을 만드는 구조가 도메인 계층 변경과 일관되게 맞춰져 있습니다.
  또한, 이후에 다시 ReportProgress.allCases를 순회하면서 전체/각 상태별 count를 재계산해 progressSubject에 흘려주는 부분도 자연스럽습니다.

별다른 버그 포인트는 안 보이고, 필요하다면 나중에 이 맵핑 로직을 별도 mapper로 분리하는 정도만 고려해 보면 될 것 같습니다.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: taipaise
Repo: YAPP-Github/Bitnagil-iOS PR: 73
File: Projects/DataSource/Sources/DTO/FilePresignedDTO.swift:8-8
Timestamp: 2025-11-22T11:34:16.094Z
Learning: In the Bitnagil-iOS project, DTOs in the DataSource module like FilePresignedDTO are intentionally kept internal (without public access modifier) when they are only used within the DataSource module and not exposed to other modules.

Learnt from: taipaise
Repo: YAPP-Github/Bitnagil-iOS PR: 25
File: Projects/Presentation/Sources/RoutineCreation/View/Component/RoutineCreationInputView.swift:104-111
Timestamp: 2025-07-27T10:05:46.043Z
Learning: RoutineCreationInputView에서 textField(_:shouldChangeCharactersIn:replacementString:) 메서드가 변경 전 텍스트를 delegate에 전달하는 이유: 변경된 텍스트를 전달하면 텍스트 입력 중에 다른 UI 액션(예: 서브루틴 추가)이 발생할 때 입력 중이던 텍스트가 손실되는 문제가 발생하기 때문. 이는 의도적인 구현으로 동시성 문제를 방지함.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 68
File: Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift:108-172
Timestamp: 2025-11-19T13:49:08.326Z
Learning: ReportCompleteViewController에서 backgroudView가 fomoImageView와 의도적으로 겹치도록 설계됨. 이를 위해 backgroudView의 top 제약을 fomoImageView.snp.top (또는 fomoImageView)을 기준으로 설정하여 오프셋을 적용함.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 19
File: Projects/Presentation/Sources/Login/View/TermsAgreementView.swift:44-46
Timestamp: 2025-07-16T09:09:13.869Z
Learning: BaseViewController의 viewDidLoad() 메서드에서 이미 configureAttribute(), configureLayout(), bind()를 호출하므로, 하위 클래스에서 super.viewDidLoad()를 호출하면 이 메서드들이 자동으로 호출된다. 따라서 하위 클래스에서 추가로 호출할 필요가 없다.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 19
File: Projects/Presentation/Sources/Onboarding/View/OnboardingRecommendedRoutineView.swift:57-59
Timestamp: 2025-07-16T09:21:15.038Z
Learning: OnboardingRecommendedRoutineView에서 viewWillAppear에 registerOnboarding 호출하는 것이 적절한 이유: 사용자가 이전 페이지에서 온보딩 선택지를 변경한 후 돌아올 때 새로운 선택지로 다시 등록해야 하기 때문. 홈 뷰에서는 이 뷰로 돌아올 수 없어서 중복 호출 문제가 발생하지 않음.

Projects/Domain/Sources/UseCase/Report/ReportUseCase.swift (2)

50-62: 이전 리뷰에서 지적된 에러 처리 문제가 여전히 남아있습니다

사진 업로드 실패 시 조용히 진행되는 현재 구현(TODO 주석, silent nil 반환, print만 하는 에러 처리)은 이전 리뷰 코멘트에서 이미 상세히 지적되었습니다. 업로드 실패 시 전체 제보 등록을 중단하고 에러를 전파하는 방식으로 개선이 필요합니다.

이전 리뷰 코멘트를 참고하여 에러 처리를 개선해 주세요.

---

46-46: 사진 필수 여부 확인 필요

사진 배열이 비어있을 때 nil을 반환하는데, 이것이 의도된 동작인지 확인이 필요합니다. 만약 제보에 사진이 필수라면 에러를 throw하여 validation 실패를 명확히 알리는 것이 디버깅에 유리합니다.

사진이 필수인 경우 다음과 같이 수정할 수 있습니다:

-        if photos.isEmpty { return nil }
+        guard !photos.isEmpty else {
+            throw ReportError.photosRequired
+        }

Projects/Presentation/Sources/Report/ViewModel/ReportRegistrationViewModel.swift (1)

111-114: 이전 리뷰 지적사항이 여전히 해결되지 않았습니다

이전 리뷰에서 지적된 문제가 그대로 남아있습니다. catch 블록에서 locationSubject에만 nil을 전송하고 self.location은 초기화하지 않아, 이전에 성공했던 위치 값이 유지될 수 있습니다. 현재 verifyIsReportValid()에서 위도/경도를 검증하고 있지만, 명시적으로 self.location = nil로 초기화하는 것이 더 안전합니다.

 private func configureLocation() {
     Task {
         do {
             self.location = try await reportUseCase.fetchCurrentLocation()
             locationSubject.send(location?.address)
             verifyIsReportValid()
         } catch {
+            self.location = nil
             locationSubject.send(nil)
             verifyIsReportValid()
         }
     }
 }

Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift (1)

83-87: configureAttribute/configureLayout 중복 호출 이슈가 여전히 남아 있습니다

BaseViewController의 viewDidLoad()에서 이미 configureAttribute(), configureLayout(), bind()를 호출하는 패턴이라면, 여기서 다시 호출하면 서브뷰/제약이 중복으로 잡힐 수 있습니다. Auto Layout 경고나 예상치 못한 UI 깨짐이 나올 수 있어, 이 VC에서도 한 번만 호출되도록 정리하는 편이 안전해 보입니다.

아래처럼 viewDidLoad에서는 액션만 트리거하도록 바꾸는 걸 제안드립니다.

override func viewDidLoad() {
    super.viewDidLoad()
-    configureAttribute()
-    configureLayout()
    viewModel.action(input: .fetchReportDetail(reportId: reportId))
}

Based on learnings, BaseViewController.viewDidLoad()에서 이미 configureAttribute/configureLayout/bind()를 호출하는 것으로 알고 있습니다.

Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift (3)

121-141: 탭바 VC 인덱스/캐스팅에 대한 방어 로직을 두는 편이 안전합니다

tabBarController.viewControllers?[0/1/2]에 바로 인덱스로 접근하고 UINavigationController로 캐스팅하는 구현은, 탭 구성이 바뀌거나 VC 수가 줄어들면 인덱스 범위 초과로 크래시가 날 수 있습니다.

예를 들어 아래처럼 viewControllers 개수와 타입을 한 번에 검증하는 쪽을 고려해 볼 수 있습니다.

guard
    let tabBarController = self.tabBarController,
    let viewControllers = tabBarController.viewControllers,
    viewControllers.count >= 3,
    let homeNav = viewControllers[0] as? UINavigationController,
    let routineNav = viewControllers[1] as? UINavigationController,
    let myPageNav = viewControllers[2] as? UINavigationController,
    let reportHistoryViewModel = DIContainer.shared.resolve(type: ReportHistoryViewModel.self)
else {
    self?.navigationController?.popToRootViewController(animated: true)
    return
}

homeNav.popToRootViewController(animated: false)
routineNav.popToRootViewController(animated: false)
tabBarController.selectedIndex = 2
myPageNav.pushViewController(ReportHistoryViewController(viewModel: reportHistoryViewModel), animated: true)

현재 구조가 고정이라면 동작에는 문제가 없겠지만, 탭 구성이 바뀔 수 있는 앱이라면 위와 같이 방어 로직을 추가하는 것을 추천드립니다.

---

206-237: summaryStackView에 컨텐츠가 재바인딩 시 중복 추가될 수 있습니다

bind()에서:

ReportCompleteContent.allCases.forEach { ... }
self?.summaryStackView.addArrangedSubview(contentStackView ?? UIView())

를 매 emit마다 실행하지만, summaryStackView의 기존 컨텐츠(특히 첫 바인딩 때 추가한 행들)를 지우지 않고 있습니다. reportDetailPublisher가 여러 번 emit될 가능성이 있다면, 동일한 행이 반복해서 쌓일 수 있습니다. (photoStackView는 이미 잘 비워주고 있어서 동일 패턴만 summaryStackView에 적용하면 될 것 같습니다.)

한 번만 레이아웃을 구성하고 이후에는 값만 업데이트하는 식으로 바꾸면 더 안전합니다. 예를 들면:

private var didSetupSummaryContent = false

override func bind() {
    viewModel.output.reportDetailPublisher
        .receive(on: DispatchQueue.main)
        .sink { [weak self] reportDetail in
            guard let self, let reportDetail else { return }

            if !self.didSetupSummaryContent {
                ReportCompleteContent.allCases.forEach { type in
                    let contentStackView = self.makeContentView(contentType: type)
                    self.summaryStackView.addArrangedSubview(contentStackView)
                }
                self.didSetupSummaryContent = true
            }

            // 이후 title/category/location/description, photoStackView 업데이트
        }
        .store(in: &cancellables)
}

또한 makeContentView는 non-optional을 반환하므로 contentStackView ?? UIView() 부분은 불필요하고, 위처럼 guard let self 이후에는 self를 강한 참조로 사용하는 편이 코드도 더 단순해집니다.

---

60-61: backgroudView 프로퍼티 네이밍 오타

backgroudView → backgroundView로 보이는 오타입니다. 동작에는 문제가 없지만, 추후 검색/리팩토링 시 혼동을 줄이기 위해 한 번에 이름을 정리해 두는 편이 좋겠습니다.

예:

-private let backgroudView = UIView()
+private let backgroundView = UIView()
...
- backgroudView.backgroundColor = BitnagilColor.gray98
- backgroudView.layer.masksToBounds = true
- backgroudView.layer.cornerRadius = 12
+ backgroundView.backgroundColor = BitnagilColor.gray98
+ backgroundView.layer.masksToBounds = true
+ backgroundView.layer.cornerRadius = 12
...
- backgroudView.snp.makeConstraints { make in
+ backgroundView.snp.makeConstraints { make in
    ...
}

규모가 큰 변경은 아니라, 이번 PR이나 후속 UI 리팩토링 때 함께 정리해도 좋을 것 같습니다.

Also applies to: 107-110, 187-191

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 19
File: Projects/Presentation/Sources/Onboarding/View/OnboardingRecommendedRoutineView.swift:57-59
Timestamp: 2025-07-16T09:21:15.038Z
Learning: OnboardingRecommendedRoutineView에서 viewWillAppear에 registerOnboarding 호출하는 것이 적절한 이유: 사용자가 이전 페이지에서 온보딩 선택지를 변경한 후 돌아올 때 새로운 선택지로 다시 등록해야 하기 때문. 홈 뷰에서는 이 뷰로 돌아올 수 없어서 중복 호출 문제가 발생하지 않음.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 68
File: Projects/Presentation/Sources/Report/View/ReportCompleteViewController.swift:108-172
Timestamp: 2025-11-19T13:49:08.326Z
Learning: ReportCompleteViewController에서 backgroudView가 fomoImageView와 의도적으로 겹치도록 설계됨. 이를 위해 backgroudView의 top 제약을 fomoImageView.snp.top (또는 fomoImageView)을 기준으로 설정하여 오프셋을 적용함.

Learnt from: choijungp
Repo: YAPP-Github/Bitnagil-iOS PR: 19
File: Projects/Presentation/Sources/Login/View/TermsAgreementView.swift:44-46
Timestamp: 2025-07-16T09:09:13.869Z
Learning: BaseViewController의 viewDidLoad() 메서드에서 이미 configureAttribute(), configureLayout(), bind()를 호출하므로, 하위 클래스에서 super.viewDidLoad()를 호출하면 이 메서드들이 자동으로 호출된다. 따라서 하위 클래스에서 추가로 호출할 필요가 없다.